EnigmA Amiga Run 1995 November/EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso/earcd/program/amos/amoslist.lzh/AMOSLIST/[e-mail]_Mon Sep 4 06:40:47 1995.msg

Internet Message Format | 1995-10-02 | 4KB

Received: from svcs1.digex.net (svcs1.digex.net [204.91.197.224]) by mail1.access.digex.net (8.6.12/8.6.12) with ESMTP id GAA12611;  for  ; Mon, 4 Sep 1995 06:40:46 -0400
Received: (from daemon@localhost) by svcs1.digex.net (8.6.12/8.6.12) id DAA16688 for amos-out; Mon, 4 Sep 1995 03:52:15 -0400
Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by svcs1.digex.net (8.6.12/8.6.12) with ESMTP id DAA16685 for <[e-mail]>; Mon, 4 Sep 1995 03:52:14 -0400
Received: from ds1.acs.ucalgary.ca ([e-mail] [136.159.34.101]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id DAA07871;  for <[e-mail]> ; Mon, 4 Sep 1995 03:52:13 -0400
Received: by acs3.acs.ucalgary.ca (AIX 4.1/UCB 5.64/4.03)
          id AA30982; Mon, 4 Sep 1995 01:51:26 -0600
Message-Id: <[e-mail]>
Subject: Big Project
To: [e-mail] (Chris Hodges)
Date: Mon, 4 Sep 95 1:51:26 MDT
From: "Robert Andrew Currie" <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>; from "Chris Hodges" at Sep 3, 95 9:08 am
X-Mailer: ELM [version 2.3 PL11B]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2577
Status: RO
X-Status:

    If we are going to create a program by splitting it up
into little procedures there are a few things that must be taken
into account:

1) All procedures must leave the system in the same condition
as when they were initially called. For example you would have to
remember which screen was active and return activeness to that
screen before leaving your procedure. If this is not followed
then one person will be spending many many hours trying to figure
out how to mesh together a bunch of procedures that won't
cooperate--this will not be fun.

2) All procedures will have there own predefined variable or
storage space that only they can access. This will prevent others
from corrupting data. For example one procedure should handle all
sound effects and/or music and be responsible for maintaining the
data space as well as the assosciated variables. In essence it
should resemble object oriented programming except we will be the
only ones enforcing this restriction. Certain public variables
can be changed outside the procedure and these should be declared
as global, all others should be shared within the procedure.

3) An agreed upon documentation standard should be created and
upheld in case there are any small changes that need to be
made. This will also encompass the creation of a procedure list,
maybe daily, which will show the parameters of each completed
procedure--just in case slight changes must be made due to design
flaws or language shortcomings.

There are probably more but I can't think at this time. If we
follow the guidelines above then we should emerge with a slightly
robust game engine which may require more memory and be a slight bit
slower than a game designed by an individual but it should allow
us to create a larger game in a much shorter time span.

One thing that I have discovered(at least with Amos Creator) is
that mimicing object oriented programming in Amos makes the
program much smaller and less memory hungry. In order to fake
object oriented language, I use only one paramter in my call to
the procedure:

Procedure SOUND[REQUEST$]
Shared CURRENT_VOL,CURRENT_SAM,SOUND_ON
If REQUEST$="Load Sample"
------
------
End If
If REQUEST$="Play Sample"
------
------
End If
End Proc

This not only makes code very readable but it also solidifies
data because only one procedure accesses that data area. If data
must be passed into the procedure then a global variable is
used-- the equivalent of a public variable. Anyways, I sound like
I'm preaching now so I'll shut up and let everyone say what they
think. :)

            Robert Currie